Lab-Guide-N1K Service Chain v1 2014-05-08

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.


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


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


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.


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.


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.


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.


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.


Figure 10. Add VM Manager Window


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.


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.


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.


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.


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.


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)


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


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.


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.


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.


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.


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.


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


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.


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.


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.


a. Name: abc-db-ftp-acl.


c. Under Attribute Type, select vZone.



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.



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.


c. Under Attribute Type, select Network.

d. Attribute Name: IP Address.


f. Attribute Value: 198.18.133.111. Click OK when done.

g. Click Add under Service, and select Operator: eq (Equals).


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:


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



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



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


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



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:


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



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.


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)# 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



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.

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)# 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



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.


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.


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.


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.


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.


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.


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.


Figure 36. Cannot display the Webpage


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:


Figure 37. Node: VSG Module:3 - 1

Figure 38. Node: VSG Module:3 - 2

Figure 39. NetScaler Module:3 -1


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.


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 line

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:


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

Lab-Guide-N1K Service Chain v1 2014-05-08

Documents

Transcript of Lab-Guide-N1K Service Chain v1 2014-05-08