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.