You are on page 1of 45

Cisco Demo Cloud (dCloud)

Cisco dCloud: The Cisco Demo


Cloud

2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 45
Cisco Nexus 1000V:
Deploying Citrix NetScaler 1000V and Cisco VSG in
vPath Service Chain
Last Updated: 08-MAY-2014
About This Lab
The objective of this lab is to introduce network engineers to the concepts of the Cisco Virtual Services Data Path (vPath). Cisco
vPath Service Chaining is a new model of delivering virtual services for the dynamic virtualized or cloud-based data center. Cisco
vPath provides embedded intelligence within Cisco Nexus 1000V Series Virtual Ethernet Modules (VEMs) to dynamically apply
multiple services to virtual machine (VM) traffic. vPath communicates with service nodes over vPath overlay tunnels, decoupling
service nodes from underlying network topology.
The Cisco vPath architecture provides a forwarding-plane abstraction and a programmable framework for inserting or removing
network services such as distributed and edge firewalls, load balancers, and WAN optimization at the hypervisor layer. Before
vPath Ecosystem Service Chaining, vPath supported only Cisco virtual network services chained per port-profile. With vPath2.5
ecosystem release, you can add Cisco and 3rd party virtual services, such as Citrix NetScaler 1000V, seamlessly in a service
chain per port-profile.
This guide explains Cisco vPath Service Chaining architecture, provides deployment guidelines, and walks you through the
configuration of VSG and Citrix NetScaler 1000V into vPath Service Chaining.
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.


2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 2 of 45
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]
Accept any certificates or warnings.
Option 2: Use Cisco AnyConnect [Show Me How] and the local RDP client on your laptop. [Show Me How]
Accept any certificates or warnings.
Cisco dCloud
This lab is hosted in Ciscos cloud-based hands-on and demo lab. Within this lab, you are provided with your personal dedicated
virtual pod (vPod). You connect via RDP to a so-called Cisco dCloud workstation within this host and walk through the lab steps
below. All necessary tools to complete this lab can be found in the Cisco dCloud workstation. Refer to the Lab Preparation
section for details on how to reach the Cisco dCloud workstation within your lab session.
The username and password to access the Cisco dCloud Workstation of this vPod are listed below:
User Name: dcloud\demouser
Password: C1sco12345
Figure 1. Demonstration Topology



2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 3 of 45
vPath Chaining Design
Cisco dCloud uses a virtualized environment in their Cisco UCS servers. One of the things that they have recently learned is the
vPath chaining within Nexus1000V. They have a two-tier datacenter architecture that comprises of two web-servers and a backend
database. They want to place a load-balancer in front of the webservers to load-balance traffic on a round robin basis. They also
want to make sure that workstations on the local segment cannot access the database server directly. A Cisco VSG will be
leveraged to restrict east-to-west traffic within this architecture. Below we show the proposed network topology for vPath chaining
and the logical topology.
Figure 2. Network Topology

Figure 3. Logical Topology



2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 4 of 45
Design Requirements
The security requirements are as follows:
1. Leverage Citrix NetScaler to load-balance traffic across the two webservers using a round robin algorithm.
2. Leverage Cisco VSG to restrict east-to-west traffic within this architecture.
3. Windows 7 client should not be able to access the Database server directly. Client should be able to SSH into the server for
management.
4. Windows 7 client should be able to access the web-servers using the VIP (virtual IP).
5. Chain traffic from NetScaler and VSG into vPath.
To achieve the requirements, the administrator has proposed a solution that includes:
1. Leverage VSG to restrict web traffic from Windows 7 client to the Database server. Allow SSH through VSG.
2. Leverage NetScaler to load-balance traffic to the webservers.
3. Use Cisco Prime solution for management of vPath chaining.
4. Leverage VSG to allow Windows 7 client to talk to the webservers through their Virtual IP address (198.18.133.111). The
following sections cover a solution to meet the requirements. Sections 4 through 7 guide you through implementing the
proposed solution.


2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 5 of 45
Scenario 1. Component Registration
In this lab, the following components have already been installed and are not the focus of the lab:
1. Virtual Cisco Prime Network Services Controller (Cisco Prime NSC):
a. IP Address is 198.18.133.85.
b. Use admin and C1sco12345 as user credentials.
c. PNSC is already registered to vCenter.
2. Nexus 1000V:
a. Installed Virtual Supervisor Module (VSM). The data IP is 198.18.133.40.
b. VSM already registered to vCenter.
c. ESXi server contains Virtual Ethernet Modules (VEMs) that are already registered to the VSM.
d. The VSM is already registered with PNSC.
3. Virtual Security Gateway (VSG) Virtual Machine:
a. Installed VSG with the management IP is 198.18.133.86.
b. VSG will be assigned to ORG-ABC. Refer to Section 6 for instructions.
c. VSG is already registered with PNSC.
4. Citrix NetScaler 1000V:
a. Installed NetScaler 1000V with the management IP of 198.18.133.109.
Verify Registration of Nexus 1000V into Prime NSC
The very first step is to verify Nexus1000V register into Cisco Prime NSC. Follow the steps below:
1. SSH into Nexus 1000V 198.18.133.40 via PuTTY. Use admin as login and C1sco12345 as password.
2. On the command line, enter the following command to check the status of Nexus 1000V registration into Prime NSC:
VSM# show vnm-pa status
VNM Policy-Agent status is - Installed Successfully. Version 2.1(1b)-vsm
Verify Registration of VSG into Prime NSC
After registering Nexus 1000V, you can then verify Cisco VSG register into Cisco Prime NSC. Follow the steps below:
1. SSH into VSG 198.18.133.86 from PuTTY. Use admin as login and C1sco12345 as password.
2. On the command line, enter the following command to check the status of VSG registration into Prime NSC:
VSG# show vnm-pa status
VNM Policy-Agent status is - Installed Successfully. Version 2.1(1b)-vsg
Verification of Registered Components in PNSC
To verify that the Nexus1000V and VSG services are registered with Cisco Prime Network Services Controller, access the Cisco
Prime Network Services Controller GUI interface using Cisco Prime Network Services Controller management IP address
(198.18.133.86) in web browser as shown below.


2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 6 of 45
1. Open IE and type https://198.18.133.85/#. Use admin and C1sco12345 as credentials to login.
2. Navigate to Administration > Service Registry > Clients > VSG and verify that your VSG is registered properly as shown in
Figure 4. Similarly, navigate to Administration > Service Registry > Clients > VSM to verify that your Nexus 1000V VSM is
also successfully registered.
Figure 4. VSG Registration

Figure 5. VSM Registration

Verify Status of NetScaler 1000V and Other Virtual Machines in vCenter
Before proceeding with the lab, we need to make sure that the NetScaler 1000V is operative. Please follow these steps:
1. On the desktop of your Cisco dCloud Workstation, you will find a vSphere shortcut. Double-click on it.
Figure 6. vSphere Shortcut

2. On the vSphere login window, leave the default settings and click on Login.


2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 7 of 45
Figure 7. vSphere Login Window

NOTE: If you are not able to connect to the vCenter, please make sure the vpxd service is running on the VC1 machine. From the
Cisco dCloud Workstation, open a command line window and enter the following command:
C:\Users\demouser> sc \\vc1 start vpxd
For more details on how to do it, have a look at the Demo Troubleshooting section at the end of this document.

3. Verify that the virtual machine ns1000v and the other virtual machines are powered up.



2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 8 of 45
Figure 8. ns1000v Pane

Verify Connection between PNSC and vCenter
1. If not open yet, please open IE and type https://198.18.133.85/#. Use admin and C1sco12345 as credentials to login.
2. Navigate to Resource Management > VM Managers. On the left pane, click on VM Managers. Verify the Operational State
of the VM Manager vCenter is up.
Figure 9. VM Managers Pane

3. If the Operation State is different than up please select the VM Manager (vCenter) and right-click on Delete. Then proceed to
add a new one by right-clicking on Add VM Manager, enter vCenter as name and 198.18.133.30 as IP address. Click OK.
The operational state should be up after that.



2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 9 of 45
Figure 10. Add VM Manager Window




2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 10 of 45
Scenario 2. Citrix NetScaler Configuration
As part of configuring NetScaler 1000V as Virtual Load Balancer with vPath, there are three things well be setting up in NetScaler
1000V Web Interface:
1. NetScaler SNIP Address
2. vPath Parameter
3. Load Balancing Virtual Server and Services
Configuring NetScaler Addressing
The management IP address has already been configured for the NetScaler VM in the architecture. Follow steps below to assign
the initial configuration parameter for the appliance.
1. Open IE and type http://198.18.133.109. Use nsroot and C1sco12345 as credentials.
2. Navigate, using the left panel to System > Network > IPs and verify the NetScaler management IP address. This is the IP
marked as Netscaler IP type.
3. Double-click on the Subnet IP address and verify that 198.18.133.110, with 255.255.192.0 mask, are listed as the Subnet IP
address.
Figure 11. IPs Pane

Subnet IP (SNIP) on NetScaler 1000V is used for backend service monitoring, keep alive and for vPath communications. Existing
SNIP can be used to carry vPath (Server VM) <-> NetScaler 1000V traffic or you can choose to use a dedicated SNIP.


2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 11 of 45

4. All the data to and from NetScaler 1000V to Backend Service VM is vPath encapsulated. We need to verify the vPath
parameter (Source IP for vPath traffic) in NetScaler 1000V. Go to Configuration > System > Network > Configure vPath
Parameters. Verify SNIP address (198.18.133.110) from the drop-down menu as shown in below.
Figure 12. Configure vPath Parameter Pane


Enabling NetScaler Load-Balancing
1. The Citrix NetScaler is used to load-balance traffic across two web-servers. Enable this feature by going to Configuration >
System > Settings > Configure basic features and selecting the Load Balancing box, as shown below.
2. Click OK to confirm.


2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 12 of 45

3. One of the great features that we can have with the NetScaler 1000V is the ability to preserve the source IP of clients for the
webservers. To configure this feature go to Configuration > System > Settings > Configure modes and verify that the Use
Source IP checkbox is ticked as shown below.
4. Click OK to confirm.

There are three things we will be setting up under the Configuration > Traffic Management > Load Balancing section in
the navigation pane in the same order:
1. Servers
2. Services
3. Virtual Server
All the Load Balancing Configuration is done from Configuration > Traffic Management > Load Balancing tab.


2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 13 of 45
Defining Web-Servers into NetScaler
Define the two webservers of our topology into the NetScaler by following the steps below:
1. Go to Configuration > Traffic Management > Load Balancing > Servers, click Add and specify the following parameters as
shown below:
a. Server Name: webserver1.
b. IP Address: 198.18.1.181. Click Create and Close when done.
2. Go back to Configuration > Traffic Management > Load Balancing > Servers, click Add and specify the following
parameters for the second web-server:
a. Server Name: webserver2.
b. IP Address: 198.18.1.182. Click Create and Close when done.
NOTE: Please be aware that clicking Create will not close the window. It remains open so that further configuration can be carried
out. Click Close when done.
Figure 13. Create Server Pane

Defining Load-Balancing Services into NetScaler
After defining the servers, we need to add them as a service (HTTP). Follow the steps below to define the service.
1. Go to Configuration > Traffic Management > Load Balancing > Services, click Add and specify the following parameters
as shown below:
a. Service Name: webservice1.
b. Under Server, select: webserver1.
c. Protocol: HTTP.
d. Port: 80.
e. Monitors: http > Add. Click Create and Close when done.


2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 14 of 45
2. Go back to Configuration > Traffic Management > Load Balancing > Services, click Add and specify the following
parameters for the second web-server.
a. Service Name: webservice2.
b. Under Server: select webserver2.
c. Protocol: HTTP.
d. Port: 80.
e. Monitors: http > Add. Click Create and Close when done.
Figure 14. Create Service Pane

NOTE: Service state will appear as Down. That is because we have not yet assigned NetScaler1000V (ADC) as a service in
Nexus1000V vPath for Web Servers 1 and 2 port-profile. This task is done in the 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 Servers.
Defining Virtual Load-Balance Server into NetScaler
After defining the services, we need to define a Virtual IP address (VIP). The VIP is used for Load Balancing Virtual Server IP
address, and needs to be configured in Load Balancing section in the subsequent steps.
1. Go to Configuration > Traffic Management > Load Balancing > Virtual Servers, click Add and specify the following
parameters as shown below:
a. Name: lweb-lb.
b. IP Addressed Based: Enabled.
c. IP Address: 198.18.133.111.


2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 15 of 45
d. Protocol: HTTP.
e. Port: 80.
f. Select Active for both webservice1 and webservice2 under Services.
g. Click the Method and Persistence tab and select Round Robin as the LB Method. Click Create and then click Close.
Figure 15. Create Virtual Server (Load Balancing)




2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 16 of 45
Scenario 3. Cisco Prime NSC Tenant Configuration
Multi-tenancy is a core concept of cloud computing, and the tenant concept can be applied in many ways. Tenants could represent
different companies sharing a public cloud service, or represent different departments/ Business groups in a private enterprise
datacenter. A tenant is simply a logical container for virtual machines, networking, security services, etc.
Cisco Prime Network Services Controller and vPath is multitenant aware. Each tenant administrator will get respective tenant view
in Cisco Prime Network Services Controller. Cisco VSG services are deployed per Tenant. Cisco VSG provides the compute
firewall for inter-tenant communication or East-West communication.
To create a new tenant within Prime NSC, follow the steps below:
1. Go to your IE window that you already have open to Cisco Prime NSC.
2. Navigate to Tenant Management > root in the left pane. Click on Create Tenant, use ORG-ABC as tenant name and click
OK, put some description in a Description field.
Figure 16. Create Tenant Pane

NOTE: Please be aware that the Tenant name on NSC and VSM must match, it is case sensitive. For this lab, we will use ORG-
ABC, all in capitals.
Adding Zones to Tenant
Logical zones can be created using network or VM attributes or a combination of both. Zones for policy rules can be defined using
VM-context or network context, and policies can be applied to VM traffic based on logical user-defined zones.
1. Navigate to Policy Management > Service Policies > ORG-ABC > Policy Helpers > vZones and click Add vZone to add
vZones for this tenant. You should configure two vZones:
DB-Zone.
Web-Zone.
As shown below, DB-Zone is being added. (Please ignore the App-Zone in the figure below, it is not part of this lab.)


2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 17 of 45
Figure 17. Add vZone Pane

2. Click Add vZone, and then enter a Name and Description.
Figure 18. Add vZone

3. Click Add Zone Condition for the DB-Zone. As shown below, a VM, Attribute Type is selected, where the attribute name is
VM Name; operator is contains (Contains String) and the attribute value is the string DB. Click OK then OK.


2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 18 of 45
Figure 19. Add Zone Condition for DB-Server Pane

4. Similarly Add Zone Condition for Web-Zone. Use Web-Zone for the name and Org ABC Web Servers as the description.
As shown below a VM attribute type is selected, where the attribute name is VM Name; operator is contains (Contains
String) and the attribute value is the string Web. Click OK then OK.
Figure 20. Add Zone Condition for Web-Zone Pane

NOTE: The value for Attribute Value is case sensitive! Prime NSC will therefore differentiate between e.g. WEB or Web. Ensure
that you enter the value exactly as the name of the VM appears in vCenter.



2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 19 of 45
Scenario 4. Cisco VSG Configuration
Cisco VSG uses three network interfaces in the following order:
1. VSG data interface (aka service interface)
2. VSG management interface
3. HA Interface
Configure Proxy-Arp on SVI or upstream router for VSG data interface. When encapsulated traffic that is destined to a Cisco VSG
is connected to a different subnet other than the host service vmknic subnet, the VEM does not use the hypervisor host routing
table. Instead, the vmknic initiates an ARP for the remote Cisco VSG IP addresses. You must configure the upstream router to
respond by using the proxy ARP feature. The VEM does not support a routing functionality and it is assumed that the upstream
switch/router is configured with the Proxy-ARP configuration.
NOTE: In this lab, Proxy-ARP has already been configured on the upstream router. We do not have management access to it, so it
is out of the scope of this guide.
The existing management VLAN in your setup can be used to manage VSG.



2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 20 of 45
Assigning VSG to a Tenant
Previously, we registered VSG to Cisco Prime Network Services Controller. Consequently, it is visible to Prime NSC but it is not
associated with any tenant or policies. Follow steps below to create Compute Firewall for your tenant and associate with VSG
instance that you've deployed.
1. While logged into Prime NSC as admin, navigate to Resource Management > Managed Resources and select root > ORG-
ABC > Compute Firewalls in the left pane. Click Add Compute Firewall and add the attributes, as shown below:
a. Name: abc-vsg.
b. Hostname: abc-vsg.
c. Device Configuration Profile: default.
d. Click Next.
Figure 21. Add Compute Firewall Pane

2. On the next page, select the VSG device that was registered into NSC.
3. Click Assign VSG radio button and then from the VSG Device drop-down choose IP address 198.18.133.86. Click Next.


2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 21 of 45
Figure 22. Select VSG Device Pane

4. On the next page, configure the data IP address. Use 198.18.4.86 as the Data IP address and specify 255.255.255.0 as the
subnet mask, as shown below. Click Next.


2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 22 of 45
Figure 23. Configure Data Interface Pane

5. Review summary of your configuration and then Click Finish to push configuration to your VSG device.
6. Verify that Prime NSC has pushed your configuration by opening a SSH session into VSG (198.18.133.86) with username:
admin and password: C1sco12345. Issue the show interface brief command as shown below.
Figure 24. Show Interface Brief Command




2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 23 of 45
Scenario 5. VSG Policy Configuration
VSG controls the East-to-West traffic by applying VM access policy rules. The security policy in Cisco Prime Network Services
Controller uses network attributes, VMware VM attributes, and VM custom attributes (see the access control list rule construct
below). You can define multiple policies for a tenant. All the policies are published to the VSG through a security profile. These
policies can be applied at any organizational level within a tenant. Policies can be assigned using VM attributes, network attributes,
or logical user-defined zones using these attributes.

Defining Security Policies
A firewall policy is used to enforce network traffic on a Cisco VSG. A key component operating on the Cisco VSG is the policy
engine. The policy engine uses the policy as a configuration and executes it when enforced against the network traffic that is
received on the Cisco VSG.
A policy is bound to a Cisco VSG by using a set of indirect associations. The security administrator can configure a security profile
and then refer to a policy name within the security profile. The security profile is associated with a port profile that has a reference
to a Cisco VSG.
Security profiles are configured in Cisco Prime Network Services Controller Policy Management interface. The predefined zones
can be used to define the security policy for each tenant.
NOTE: The security policy requirements are listed below for convenience:
Leverage Citrix NetScaler to load-balance traffic across the two webservers using a round robin algorithm.
Leverage Cisco VSG to restrict east-to-west traffic within this architecture.
Windows 7 client should not be able to access the Database server directly. Client should be able to SSH into the server for
management.
Windows 7 client should be able to access the web-servers using the VIP (virtual IP).
Chain traffic from NetScaler and VSG into vPath.
Follow steps below to define a security policy to meet our security requirement.


2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 24 of 45
1. While logged into Prime NSC as admin (password: C1sco12345), navigate to Policy Management > Service Profiles >
ORG-ABC > Compute Firewall > Compute Security Profiles and select Add Compute Security Profile. Configure the
name of the profile as abc-profile. Click Add ACL Policy Set. Configure abc-acl-policy as the policy name. Click Add ACL
Policy. Configure abc-acl as the ACL policy name and click Add Rule, as shown below.
Figure 25. Add ACL Policy Pane

2. Define our first rule to permit traffic from our Windows 7 client to the webservers. Use the information below to define this rule.
a. Name: abc-web-acl.
b. Action to take: permit, and click Add under Destination Conditions.
c. Under Attribute type, select vZone.
d. Attribute Name: vZone Name.
e. Operator: eq (Equals).
f. Attribute Value: Web-Zone. Click OK when done.


2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 25 of 45
Figure 26. Add Rule Condition Pane

3. Click Add under Service, and select Operator: eq (Equals).
4. Protocol: TCP (6).
5. Port: Other, 80; as shown below. Click OK twice.
Figure 27. Edit Rule Condition Pane

6. Click Add Rule, and define our second rule to permit FTP traffic from our Windows 7 client to the database server. Use the
information below to define this rule.


2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 26 of 45
a. Name: abc-db-ftp-acl.
b. Action to take: permit, and click Add under Destination Conditions.
c. Under Attribute Type, select vZone.
d. Attribute Name: vZone Name.
e. Operator: eq (Equals).
f. Attribute Value: DB-Zone. Click OK when done.
g. Click Add under Service, and select Operator: eq (Equals).
h. Protocol: TCP (6).
i. Port: Other, 21. Click OK twice.
7. Click Add Rule, and define our third rule to permit traffic from our web-servers to the database server. Use the information
below to define this rule.
a. Name: abc-web-db-acl.
b. Action to take: permit, and click Add under Source Conditions.
c. Under Attribute type, select vZone.
d. Attribute Name: vZone Name.
e. Operator: eq (Equals).
f. Attribute Value: Web-Zone. Click OK when done.
g. Click Add under Destination Conditions.
h. Under Attribute Type, select vZone.
i. Attribute Name: vZone Name.
j. Operator: eq (Equals).
k. Attribute Value: DB-Zone. Click OK when done.
l. Click Add under Service, and select Operator: eq (Equals).
m. Protocol: TCP (6).
n. Port: Other, 80. Click OK twice.
8. Click Add Rule, and define our fourth rule to permit web traffic from our Windows 7 client to the VIP of the web-servers. Use
the information below to define this rule.
a. Name: abc-web-vip-acl.
b. Action to take: permit, and click Add under Destination Conditions.
c. Under Attribute Type, select Network.
d. Attribute Name: IP Address.
e. Operator: eq (Equals).
f. Attribute Value: 198.18.133.111. Click OK when done.
g. Click Add under Service, and select Operator: eq (Equals).


2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 27 of 45
h. Protocol: TCP (6) .
i. Port: Other, 80. Click OK twice.
9. Click Add Rule, and define our fifth rule to deny and log all other traffic through the VSG. Use the information below to define
this rule.
a. Name: abc-drop-acl.
b. Action to take: drop, log.
c. Condition match criteria: match-all. Click OK/Apply accordingly to exit the creation of rules.
The final ACL should look like below.
Figure 28. Final ACL Window

Verifying Policy Assignment on the VSG
After the policy has been created on the Prime NSC in previous steps, the configuration is already pushed into the corresponding
VSG. A key component operating on the Cisco VSG is the policy engine. The policy engine uses the policy as a configuration and
executes it when enforced against the network traffic that is received on the Cisco VSG.
After the policy has been created on the Prime NSC in previous steps, the configuration is already pushed into the corresponding
VSG. You can verify that the policy contained in the VSG corresponds to the previously configured one.
Connect to the VSG via SSH and validate that the policy has been successfully published from Prime NSC, as shown below:
1. SSH into VSG using PuTTY (198.18.133.86; username: admin; password: C1sco12345) and issue show running-config
policy as shown below:


2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 28 of 45



2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 29 of 45
Scenario 6. N1000V vPath Configuration
Once the security profile and firewall policy are fully developed, the administrator binds the security profile with the VM port profiles
that demand access protection provided by the Cisco VSG through the port profile management interface on the VSM. As
administrator, you must also bind the Cisco VSG with the set of VM port profiles.
The virtual machines named Webserver-A and Webserver-B within the lab environment are already associated to the Nexus
1000V port-profile called TenantA-Web. While Windows 7 and DB-Server-A are associated with the Nexus 1000V port-profile
called Client and TenantA-DB respectively. Below the current configuration of the port-profiles.
NOTE: Please do not get confused with the name of the Port Profiles. Regardless the name, the port profiles will be linked to our
created tenant when using the command org root/ORG-ABC a few steps forward.
The port-profile TenantA-Web has the following network configuration:
abc-n1k# show run port-profile TenantA-Web
port-profile type vethernet TenantA-Web
vmware port-group
switchport access vlan 502
switchport mode access
no shutdown
state enabled
The port-profile TenantA-DB has the following network configuration:
abc-n1k# show run port-profile TenantA-DB
port-profile type vethernet TenantA-DB
vmware port-group
switchport access vlan 502
switchport mode access
no shutdown
state enabled
The port-profile Client has the following network configuration:
abc-n1k# show run port-profile Client
port-profile type vethernet Client
vmware port-group
switchport access vlan 501
switchport mode access
no shutdown
state enabled
Understanding Communication between VEM (vPath) and VSN (VSG, NetScaler)
Virtual Service Node (VSG, NetScaler1000V, vWAAS etc), aka VSN, receives traffic from the VEM when service is enabled on a
port profile. The redirection of the traffic occurs using vPath. vPath encapsulates the original packet and sends it to VSN. VSN has
a service or data interface (example Data0 in VSG, or SNIP in NS1000V) with an IP address for vPath communication.
All service nodes should be L3 adjacent to vPath. In this configuration, Layer 3 communication will be through the virtual service
nodes 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 Nodes 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.
For Layer 3 adjacency, you can use the same VMkernel interface on protected host, that's used for VSM and VEM control traffic,
for communication between Cisco VSG and VEM. This is achieved by adding capability l3-vservice to the same port profile as the
one used for VSM and VEM (Layer 3 control) communication. In this case, all your data traffic will flow through this interface along
with ESXi management and Nexus 1000V control traffic. In this lab, The NetScaler appliance is using the same port profile as the


2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 30 of 45
N1000V management, port profile: n1kv_mgmt_vlan. You can verify this configuration on your VSM (Nexus 1000V switch) by
issuing the show run port-profile n1kv_mgmt_vlan command.
abc-n1k# show run port-profile n1kv_mgmt_vlan
port-profile type vethernet n1kv_mgmt_vlan
capability l3control
vmware port-group
switchport mode access
switchport access vlan 700
capability l3-vservice
system vlan 700
no shut
state enabled
Define vService Node for VSG
To enable VM Firewall and Load Balancing service policies for VM workload in the network, you need to attach these services to
port-profile on Cisco Nexus 1000V Series. In case of VSG you will also bind tenant compute security profile defined in Prime NSC,
to the port-profile. All the traffic traversing the virtual ports associated with that port profile is subjected to policy evaluation.
Connect to the VSM via SSH and follow the steps below to define vservice node for VSG.
1. SSH into VSM (198.18.133.40; username: admin; password: C1sco12345) and verify the vservice node named VSG for
VSG, shown below:

NOTE: This service node has already been configured. The node name is VSG.
Define vService Node for NetScaler
To define NetScaler1000V service node, you need to use NetScalers vPath Interface IP address (or the Subnet IP configured
above in section 6). Connect to the VSM via SSH and follow the steps below to define vservice node for NetScaler:
1. While connected to VSM, verify the vservice node for NetScaler, shown below:



2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 31 of 45
NOTE: This service node has already been configured. The node name is NS1Kv.
Chaining VSG and NetScaler Services
Use the service path to define service chaining with multiple service nodes, in a specific order. The order for service nodes
chaining should be applied Inside-to-Outside for traffic from Server>Client. This is where you apply security profiles created for
VSG, and ADC or Load Balancing policy of NetScaler 1000V to the service path (service chain). Follow the steps to define service
chaining within Nexus 1000V:
1. While connected to VSM, go into the configuration mode to configure vService path. We are chaining VSG (order 10) and then
NetScaler (order 20) in a vService path called abc-vpath. Follow the steps below to get it done:
VSM# conf t
Enter configuration commands, one per line. End with CNTL/Z.
VSM(config)# vservice path abc-vpath
VSM(config-vservice-path)# node VSG profile abc-profile order 10
VSM(config-vservice-path)# node NS1Kv order 20
After defining the vPath chaining, you must apply this to a port-profile that faces our webservers. You also need to specify which
tenant this port-profile belongs to.
2. While connected to VSM, go into the configuration mode to reconfigure the port-profile for our newly configured vPath, shown
below:
VSM# conf t
Enter configuration commands, one per line. End with CNTL/Z.
VSM(config-vservice-path)# port-profile type vethernet TenantA-Web
VSM(config-port-prof)# org root/ORG-ABC
VSM(config-port-prof)# vservice path abc-vpath
After configuring it, type show run port-profile TenantA-Web and compare the output with the configuration shown below:
port-profile type vethernet TenantA-Web
vmware port-group
switchport access vlan 502
switchport mode access
org root/ORG-ABC
vservice path abc-vpath
no shutdown
state enabled
Once port-porfile is vPath enabled, type show vservice brief and verify that the state of both nodes in this service chain are alive.


2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 32 of 45

3. Type exit.
Since we also need to block direct communication between the Windows 7 client and the database server (one of our
requirements), we need to apply the VSG policy to the port-profile that faces the client (and the database server). Additionally, you
also need to specify the tenant that this port-profile belongs to. Follow the steps below to get it done.
4. While connected to VSM, go into the configuration mode to reconfigure the port-profile for our newly configured Node, as
shown below:
VSM(config)# port-profile type vethernet Client
VSM(config-port-prof)# org root/ORG-ABC
VSM(config-port-prof)# vservice node VSG profile abc-profile
After configuring it, type show run port-profile Client and compare the output with the configuration shown below:
port-profile type vethernet Client
vmware port-group
switchport access vlan 501
switchport mode access
org root/ORG-ABC
vservice node VSG profile abc-profile
no shutdown
state enabled


2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 33 of 45
Once port-profile is mapped with VSG policy, type show vservice brief and verify that the abc-porfile is applied to port-profile
Client.

5. While connected to VSM, go into the configuration mode to reconfigure the port-profile for our newly configured node, as
shown below:
VSM(config-port-prof)# port-profile type vethernet TenantA-DB
VSM(config-port-prof)# org root/ORG-ABC
VSM(config-port-prof)# vservice node VSG profile abc-profile
After configuring it, type show run port-profile TenantA-DB and compare the output with the configuration shown below:
port-profile type vethernet TenantA-DB
vmware port-group
switchport access vlan 502
switchport mode access
org root/ORG-ABC
vservice node VSG profile abc-profile
no shutdown
state enabled
Once port-profile is mapped with VSG policy, type show vservice brief and verify that the abc-porfile is applied to port-profile
Client.


2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 34 of 45

IMPORTANT: If the IP address does not display, you will need to ping the DB-Server from the workstation. From the
demonstration workstation, open a Command Window (you will find the shortcut [ ] on the taskbar) and enter the following
command: ping 198.18.1.191.



2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 35 of 45
Scenario 7. vPath Verification
Once everything is configured, lets verify if the lab is working as expected.
Verifying NetScaler Load-Balancing Service
1. The first step is to verify if NetScaler service is up to load-balance our traffic across two web-servers.
Log into I.E. (IP: 198.18.133.109, user: nsroot, password: C1sco12345) and verify that the load-balance Virtual Server and
Services status shows as UP. You can navigate to Configuration > Traffic Management > Load Balancing > Services and
Configuration > Traffic Management > Load Balancing > Services, as shown below.
Figure 29. Load-Balancing Service Window


Verifying Windows 7 Client Connectivity
The next step is to verify the services inserted in the traffic flow by accessing Webserver at port 80 using VIP IP in the Windows 7
client browser. In order to do this, you need to open the Windows7 virtual machine console window from vSphere Client. Follow the
steps below.
1. On the desktop of your Cisco dCloud Workstation, you will find a vSphere shortcut. Double-click on it.

2. On the vSphere login window, leave the default settings and click on Login.


2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 36 of 45
Figure 30. vShere Login

3. Once you are logged in, click Home > Hosts and Clusters. Right click on the Windows 7 Virtual Machine and select Open
Console.
Figure 31. Open Console Pane

4. Once the console window is open, login as demouser with password: C1sco12345.
5. You will find a shortcut on the Windows7 Virtual Machines desktop. Double click on it in order to verify connectivity to the load
balanced VIP (http://198.18.133.111). The web browser should reach one of the two webservers as shown below.


2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 37 of 45
Figure 32. Webserver Window 1

Figure 33. Webserver Window 2

6. Now let us make sure that load balancing is working. Launch another Internet Explorer from your Windows 7 client and go to
the same URL http://198.18.133.111. This time you should reach the other webserver as shown below.


2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 38 of 45
Figure 34. Webserver-B Window

NOTE: Due to browser cache features, you might have to refresh the page more than once.
7. After checking the load balancing services on the web servers we can check the security services on the database server. We
should be able to FTP to the DB server but not open a webpage. First try FTP. From your Windows7 client open a Command
Window (you will find the shortcut on the taskbar) and enter the following command:
C:\Users\Demouser> ftp 198.18.1.191
You should be asked for credentials but if you got that far is because the VSG is allowing you access to it. No need to go
further.


2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 39 of 45
Figure 35. Login Successful Window

8. Now try to access the DB Server via HTTP. Open IE again and enter http://198.18.1.191 in the URL bar. Press enter and see
if you get a connection. This connection should timeout as the VSG is blocking the connection.


2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 40 of 45
Figure 36. Cannot display the Webpage




2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 41 of 45
Scenario 8. Using Command Line for Verifying Statistics
Verify Statistics and live connections on Virtual Supervisor Module or on VSG and NetScaler1000V Monitoring Console, to get
information on number of packet flows, flow policy hits, or policy miss and actions implemented for the flow. Use the show
vservice connection and show vservice statistics commands on Nexus 1000V to access the statistics and connection details.
The show vservice connection offers information of the current connections using the active network services (load balancing,
security). In the screenshot below we can see how the NetScaler (198.18.133.110) is monitoring health of webserver2
(198.18.1.182).
NOTE: The output of the show vservice connection command shows the current packet transations in real-time. The screenshot
below is an example of the output as the results varry depending on the current network activity.

The show vservice statistics offers statistics per each Node per each Module. The output shown below is partial and only shows
stats for Module3 (VEM) for both nodes, the NetScaler and the VSG:


2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 42 of 45
Figure 37. Node: VSG Module:3 - 1


Figure 38. Node: VSG Module:3 - 2


Figure 39. NetScaler Module:3 -1




2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 43 of 45
Figure 40. NetScaler Module:3 - 2

Another great command to verify your VSG is working properly is to look at hit counts on your policy. Login to your VSG via SSH
(198.18.133.86, admin/C1sco12345) and run the show policy-engine stats command.



2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 44 of 45
Demo Troubleshooting
Not able to connect to vCenter

If not able to connect to the vCenter, most likely the service has failed to start. We can start it remotely from a command l ine
window in the Cisco dCloud Workstation. Open a command line window in Cisco dCloud Workstation, you should find a shortcut
on the taskbar.

In the command line window, enter the following command:

Also, we can query the status of the service by using the following command:


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

If we get the RUNNING state, we should be able to access vCenter now.

You might also like